Secure data accessing system and method

ABSTRACT

A system and method for accessing data located behind a security mechanism is provided. In the preferred embodiment, the system may use the common HTTP protocol and JDBC drivers. In more detail, a client may execute a Java applet that generates database proxy objects that are communicated to an application server using the HTTP protocol. The application server may use a servlet to process the objects and generate database requests using JDBC drivers so that the data is retrieved from the database for the client Java applet without the security problems.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/098,203, filed on Apr. 4, 2008 and entitled “Secure Data AccessingSystem and Method,” (now U.S. Patent Publication No. 2008/0250028 A-1),which is a continuation of U.S. patent application Ser. No. 09/872,502,filed on Jun. 1, 2001 and entitled “Secure Data Accessing System andMethod,” (now U.S. Pat. No. 7,428,752), the disclosure of each of whichis incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The invention relates generally to a system for accessing a computer andits database and in particular to a system and method for accessingdata, such as in a database, that is protected by/located behind atypical computer security system, such as a typical firewall.

APPENDICES

The present application includes several Appendices that areincorporated into the disclosure and are part of the disclosure.Appendix A is 47 pages long and contains the source code of the variousJava classes located on the client computer that are used to implementone embodiment of the invention. Appendix B is 8 pages long and containsthe source code of the various Java classes shared by the clientcomputer and application server computer that are used to implement oneembodiment of the invention. Appendix C is 19 pages long and containsthe source code of the various Java classes located on the applicationserver that are used to implement one embodiment of the invention.

BACKGROUND OF THE INVENTION

Modernly, computer systems are being put into place wherein the softwareand data on which the computer operates may be located at one or moredisparate computer resource locations. In addition, the databases beingaccessed by the software may be located on a different computingresource and may be, for example, located on a corporate intranet sothat the resources to implement and execute the software aredistributed. To accomplish this distributed software execution, it isnecessary to be able to track the locations of the various resources onthe Internet, such as by the IP addresses, so that the softwareresources and the data from one or more databases can be retrieved asneeded. For example, pieces of the software code may be located at onelocation while the data associated with the software code may bedistributed across the Internet.

The problem with the distributed computing set forth above is that thecomputer network of most corporate users is behind a security device orsystem, such as a firewall, and/or subject to proxy servers and othersecurity measures that prevent users from easily accessing databasesoutside of the firewall. The purpose of the firewall is to protect thecomputer network from hackers outside of the system trying to get intothe computer network and to avoid a user behind the firewall fromdownloading a potentially dangerous piece of code from the Internet. Inaddition, if the software is written in Java, the applet downloaded tothe client can only interact with the server from which it wasdownloaded which is a fundamental security feature of Java. Thus, tryingto connect through the Internet to distant servers cannot be done usingJava applets with most protocols. The exception is the common hypertexttransfer protocol (HTTP). By way of background, the HTTP protocol is theprotocol used for all Internet traffic and it has over 10,000 ports. Byspecification, each port is traditionally used for certain types oftraffic. For example, Oracle® database connections traditionally useport 1521. The general unprotected port for web-site Internet traffic,by default, is port 80. In addition, secure HTTP protocol traffic(HTTPS) is typically communicated over port 433.

In approaching this problem, there are well known typical approachessuch as those described in the Sun Microsystems, Inc. Java 2.0Enterprise Edition (“J2EE”) specification. In particular, theapplication server would make the call to the database server and thenthe application server would obtain the results and create businessobjects on the application server itself. The objects would then be sentto the requesting client. In this mode of operation, the objects wouldhe resident on the application server and would then be available forother clients to use if they so chose to do so. This has the benefit ofnot duplicating effort, because the application server would maintainthe objects for all clients to use, and the client would transport theobjects back as needed. While this may be efficient, it has certaindisadvantages for a dynamic distributing computing environment, such as:(1) it requires that the applet downloaded to the client contain theclasses necessary to create the intended objects; and (2) the servermust install the same classes on itself for creating the businessobjects intended for the client. These disadvantages make the systemmuch less dynamic, and create other problems. For example, differentclients may create different objects from the same resultset that isreturned from the database and the classes required to create theobjects for all of the clients may not be available to the applicationserver.

In more detail, the clients that need a database connection may not beable to connect to the server from behind secure corporate intranets.Since corporate intranets, in general, are secured with firewalls,proxies and other security measures, the clients will have to tunnelthrough them to gain access to the external resources. Furthermore, mostfirewalls do not allow direct Internet Protocol (IP) traffic between theInternet and the internal network they are protecting. Thus, mostorganizations behind firewalls have a proxy server running that allowspeople inside the organization to access the Web. For a distributedcomputing environment across the Internet, it is necessary to allowusers to access multiple databases through these security measures.Thus, it is necessary to provide a system and method for accessing datafrom behind a corporate security system so that the distributedcomputing system can be efficiently operated and for permitting a userbehind a firewall to execute a distributed computer application, and itis to this end that the present invention is directed.

SUMMARY OF THE INVENTION

The secure data accessing system and method in accordance with theinvention overcomes the limitations associated with the typical systems.The secure data accessing system may be particularly useful for adistributed application/computing environment in which there is a needfor extensive access to a variety of database servers. To accomplish thecommunication by tunneling through a security mechanism, such as afirewall, the well known HTTP protocol is used in combination with JDBCdrivers. The JDBC drivers use a set of unique parameters for connectingto the database server. In addition, database servers, like all otherservers, require the clients to connect to them through a particularport using client libraries and/or JDBC drivers. In particular, all JDBCdrivers are required to conform to the JDBC API specifications developedby Sun Microsystems, Inc. Since all JDBC drivers are written to Javaspecifications, all of them must implement the JDBC interfaces.

In a distributed application environment that uses Java, the applet orthe stand alone application needs to communicate with the databaseserver. Java applets are only allowed to communicate with the serverthat the applet is originated/downloaded from due to securityrestrictions imposed by the Java language specification. In adistributed application environment, it is more likely that the databaseserver might be on a different server than the application server andthese servers might not be reachable by the client using protocols otherthan HTTP. In addition, JDBC drivers provided by the database vendorsconnect to the database using sockets. Furthermore, applets arerestricted from making direct socket connections to other servers forthe same security concerns. Corporate intranets need to provide accessto the Internet to their users and, by default or de facto standard, theHTTP protocol has become the preferred protocol. Therefore, the best wayfor the applets to communicate with the server in accordance with theinvention would be to use the HTTP protocol in combination with JDBCdrivers in order to be as compatible as possible with the proxy serversand network firewalls.

The HTTP JDBC driver system in accordance with the invention may also beused to solve a problem faced by systems that need to communicate with adatabase through a firewall, such as web services. The system may alsobe used effectively with other systems including peer-to-peer systems,in jini services, mobile devices with small footprints and any otherusage that requires a thin client to obtain data from a data storagedevice through a firewall, a network address translator (NAT) or othersecurity mechanism, in a dynamic powerful way. For example, a dynamicapplication system that may need to be connected to multiple databasesthat may be located behind security mechanisms such as the dynamicapplication system described at http://www.verticalsuite.com.

Unlike a more traditional approach using the J2EE specification (J2EEstands for Java 2.0 Enterprise Edition), the HTTP JDBC driver inaccordance with the invention has significant advantages. Using the HTTPJDBC driver, the application server may create a result and sends thatto the client who then creates the objects as needed at the client. Theadvantages to this approach become apparent in a dynamic, web-servicestype of environment in that it allows clients to be very thin, and tounilaterally determine the way in which they receive data. The clientthen has the power to dynamically determine how it wants the resultspresented or treated. For example, the client could choose to create itsown business objects, or it could simply manipulate the data and/orpresent it to the user.

The HTTP JDBC driver system in accordance with the invention mayaffect/be beneficial to many different existing systems. For example,the driver system in accordance with the invention may be used toimprove dynamic IP addresses. In particular, where the addresses orlocations are dynamic or not known to the client computer, the HTTPconnections could still be made with the results being sent back viaHTTP. This aspect may be crucial to a web services type of environment.The change in the IP address or the location of the database server willnot in anyway effect the client as long as the application server canconnect and the database server is able to accept the connection. Thechange in the configuration of the database will not effect theHTTP-JDBC driver setup. For example, no additional classes are neededand no additional configuration for the application is required. Theclient only has to pass the right set of changed parameters forconnecting which will be used by the application server to connect tothe database.

The driver system may be used by intelligent agents to obtain databaseaccess. In addition, jini services are built using Java components and,therefore, this driver technology could be used in a jini servicesenvironment. The driver system in accordance with the invention may alsobenefit a distributed computing system. In particular, the technologywould support distributed computing generally, across the Internet andthrough firewalls and other security mechanisms.

The HTTP JDBC driver system in accordance with the invention may also beused to enhance peer-to-peer systems. In particular, the drivertechnology may be critical in supporting peer-to-peer communicationswhere a peer needs to go through a firewall to get data from a datastorage device. In fact, in Project Jxta (http://www.Jxta.org), which isSun Microsystems's peer-to-peer specification and platform, there arespecific discussions about firewalls and network address translator's(NAT's) and the fact that you need one peer on the outside and one peeron the inside of the firewall, both being in the same peer group andable to transfer code and/or data. The driver system in accordance withthe invention may also benefit N-tiered or multi-tiered architectureswherein, regardless of the number of “clients” and “servers” or thenumber of connections, the driver system can be used to transport datasets across firewalls as many times as may be required in a complexseries of connections.

The HTTP JDBC driver system in accordance with the invention may be usedwith object-oriented databases and other new data storage devices. Forexample, the driver system will support any new data storage device,including existing types such as object-oriented databases (CloudScape),so long as the proper drivers exist which can be loaded onto theapplication server. This could become of critical importance in a webservices environment, because the client would not be altered by theaddition of new data storage devices or means. In addition, data couldbe pulled from such databases as PointBase.com (a Java relationaldatabase that has such a small footprint it can sit on a device, such asa router or vending machine).

The HTTP JDBC driver system in accordance with the invention may also beused with jini services or Web services. In an environment of the futurebuilt on jini services or web services, an application would be pulledtogether dynamically as components being assembled on the fly to createone-time applications. The driver system could act as a component to theservices to provide dynamic access to external disparate data sources.Alternatively, the driver of this invention could be provided as its ownservice.

Thus, in accordance with the invention, a system for accessing datalocated behind a security mechanism is provided. The system comprises aclient that executes a first application having a series of instructionsthat includes accessing data from a database wherein the client createsone or more database proxy objects that are used to indirectly accessthe database. The system further comprises an application server thatexecutes a second application that interacts with the database and hasone or more corresponding objects, the application server furthercomprising one or more drivers that interface with a database so thatthe application server requests data from the database. The systemcauses the client to interact with the database through the applicationserver so that a security mechanism protecting the client does notinterrupt the accessing of the data from the database.

The system comprises a client that executes a Java applet having aseries of instructions to access data from a database and creates proxyobjects in response to the database request. The system furthercomprises a Java application server that executes a servlet thatreceives the calls generated by the proxy objects on the client andfurther generates database calls using the JDBC drivers.

The application server further comprises a mechanism to send back theresults and the unique name of the object, if a new object is created onthe server, or the resultset created by the database call. Such a systemcomprised of the above-mentioned components will make it possible forthe applet to communicate with the database through the applicationserver with the help of proxy objects, and by doing so the securitymechanism protecting the client does not interrupt the database accessand the JDBC functionality is achieved.

In accordance with yet another aspect of the invention, a system foraccessing data located behind a security mechanism is provided whereinthe system comprises a client having means for creating one or moreproxy objects in response to a database request. The system furthercomprises an application server comprising means for processing thecalls received from the database proxy objects and means for using oneor more drivers to generate one or more database requests based on thecalls from the proxy objects wherein the client interacts with thedatabase through the application server so that a security mechanismprotecting the client does not interrupt the accessing of the data inthe database.

In accordance with yet another aspect of the invention a system foraccessing data by a Java applet wherein the data is located behind asecurity mechanism is provided. The system comprises a client thatexecutes a Java applet having a series of instructions to access datafrom a database and creates proxy objects in response to the databaserequest. The system further comprises a Java application server thatexecutes a servlet that receives the calls generated by the proxyobjects on the client and further generates database calls using theJDBC drivers. The application server further comprises a mechanism tosend back the results along with a unique name of the object created bythe database call, if any, or sends the resultset back to the client.Such a system comprised of the above-mentioned components will make itpossible for the applet to communicate with the database through theapplication server so that a security mechanism protecting the clientdoes not interrupt the database access.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a preferred embodiment of thesecure data accessing system in accordance with the invention;

FIG. 2 illustrates more details of the system shown in FIG. 1;

FIG. 3A illustrates a method for data accessing in accordance with theinvention using the HTTP protocol and JDBC drivers;

FIG. 3B is a block diagram illustrating the method for using the HTTPJDBC driver in accordance with the invention;

FIG. 4 illustrates a typical JDBC client database connection;

FIG. 5 illustrates a connection to a database using the HTTP JDBC driverin accordance with the invention; and

FIG. 6 illustrates an application server being used as the client foranother server in accordance with the invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The invention is particularly applicable to a distributed applicationsystem that uses Java applets, the HTTP protocol and JDBC drivers and itis in this context that the invention will be described. It will beappreciated, however, that the system and method in accordance with theinvention has greater utility, such as to other computing systemswherein users behind security mechanisms need to access external data orwhere users need to access data located behind a security mechanism. Theinvention may also be implemented with other protocols or with otherprogramming languages without departing from the scope of the invention.

FIG. 1 is a block diagram illustrating a preferred embodiment of thesecure data accessing system 20 in accordance with the invention. Inmore detail, the system may include one or more clients 22 (Client 1,Client 2, . . . , Client N), and a distributed computer applicationsystem 24. The various elements of the system, such as the clients 22and the distributed computer application system 24 may be interconnectedtogether by a communications network 26 that permits all of the elementsof the system to communicate with each other using a communicationsprotocol. In a preferred embodiment, the communications network may be acomputer network and more preferably the Internet and the World WideWeb. In a preferred embodiment, the communications over thecommunications network may be carried out using a well known protocol,such as the hypertext transfer protocol (HTTP). It may also be carriedout using a secure communications protocol such as the well known securehypertext transfer protocol (HTTPS).

Each client 22 may permit an authorized user of the system (e.g.,someone with the appropriate access privileges) to access the resourcesof the distributed computer application system 24 as will be describedin more detail below. Each client 22 may comprise a typical computersystem that may include a display device 32, such as a CRT or LCD, acomputer chassis 34 and one or more input/output devices 36, such as akeyboard 38 and a mouse 40 as shown. Each client may also include anoutput device, such as a printer (not shown) for generating a hard copyof the results of the distributed computer application being executed inaccordance with the invention. The reports may also be displayed on thedisplay device 32. The computer chassis 34 may further include a centralprocessing unit (CPU) 42 that controls the operation of the computersystem, a temporary memory 44, such as DRAM or SRAM, that stores one ormore pieces of software, such as the operating system, that are beingcurrently executed by the CPU and a persistent storage device 46, suchas a hard disk drive, optical disk drive, tape drive or the like, thatpermanently stores data and software. In order to access the distributedcomputer application system in accordance with the invention, a browserapplication 48 may be loaded from the persistent storage device into thememory as shown and executed by the CPU.

The browser application, as is well known, permits the computer toconnect to and communicate over the Internet 26 with other computersystems, such as the central computer application system 24. Forexample, the browser may communicate using a typical protocol, such asthe well known HTTP protocol or the HTTPS secure protocol as describedabove. In general, the browser initiates a communications connectionwith the computer system and then establishes the protocol. In thepreferred embodiment, the browser 48 permits a user of the client system22 to access the system, execute one or more distributed applicationsusing the distributed computer application system and receive outputfrom the distributed applications. Typically, the browser may display aseries of user interface screens, such as web pages, that permit theuser to interact with the distributed computer application system. In apreferred embodiment, the client must have, at a minimum, the Javaruntime environment which typically includes the ability to downloadapplets, to create resultset objects, and to communicate over the httpprotocol, among other things.

The distributed computer application system 24 may be one or moretypical server computer systems in the preferred embodiment wherein theone or more servers are interconnected together and communicate witheach other over the communications network 26. In this manner, thecombination of servers required to generate a distributed softwareapplication may be dispersed from each other and, when necessary,connect to each other and transfer data between each other using thecommunications network. In the example shown, the distributed computerapplication system may include an application server 60 and a databaseserver 62. In operation, a Java applet may be downloaded from theapplication server to the client so that it can be executed by theclient. The applet may generate requests that are communicated to thedatabase server over the Internet to connect to and retrieve the datafrom different databases. In a preferred embodiment, the applet to bedownloaded to the client should contain the HTTP-JDBC client classes(See Appendix A and the description below) and the common classes sharedby both the server and client (See Appendix B and the descriptionbelow). To accomplish this, the system may include a routing databasethat maintains the properties (e.g., URLs) of the various resourcesneeded to execute the distributed computer application.

In a preferred embodiment, the application server 60 will be a Javaapplication server which will have, at a minimum, an http server, aservlet engine, and the ability to host applets, among other things. Theserver should have the JDBC drivers for the database that the clienttries to connect to and the servlet that the client communicates with.The server should also have the common set of classes required by ourHTTP-JDBC driver (See Appendix B and the description below) as well asthe server side classes (See Appendix C and the description below).

As shown, the database server 62 and CLIENT #N may be located behind acorporate security mechanism 64, such as a firewall that controls theaccess of users to the resources located behind the security mechanismand controls the access that users behind the security mechanism have tothe Internet. Thus, as shown, the database server and the applicationserver are separated from each other by the security mechanism thatmakes the execution of the distributed computer application moredifficult. In a preferred embodiment, the database or datasource shouldbe able to accept connection from the Java application server using theappropriate JDBC drivers, with little or no interference from securitymeasures or firewalls. In addition, the client (CLIENT #N) and thedistributed computer application system 24 are also separated from eachother by the security mechanism that also makes the execution of thedistributed computer application more difficult as will now bedescribed.

In particular, the clients 22 that need a database connection to thedatabase server 62 to execute a distributed computer application may notbe able to connect to the server from behind secure corporate intranets.In more detail, since corporate intranets in general are secured withfirewalls, proxies and other security measures, the clients will have totunnel through them to gain access to the external resources. Theproblem is that most firewalls do not allow direct Internet Protocol(IP) traffic between the Internet and the internal network they areprotecting. For example, most organizations behind firewalls have a wellknown proxy server running that allows people inside the organization toaccess the Web and, database servers.

The distributed computer application system typically needs extensiveaccess to a variety of database servers that contain the necessary datato execute the distributed computer application. In general, JDBCdrivers use a set of unique parameters for connecting to the databaseserver and database servers, like all other servers, require the clientsto connect to them through a particular port using client librariesand/or JDBC drivers. All JDBC drivers are required to conform to theJDBC API specifications developed by Sun Microsystems, Inc. Since allJDBC drivers are written to Java specifications all of them mustimplement the JDBC interfaces. The distributed computer applicationsystem in accordance with the invention connects and accesses data fromdatabases using the JDBC drivers developed by the database vendors orthird party developers. While connecting to the database server from theclient seems to be an easy solution, JDBC drivers provided by thedatabase vendors connect to the database using sockets and Java appletsare restricted from making direct socket connections to other servers.

In a distributed computer application environment, the Java applets thatmay be used by the distributed computer application system to executethe application, need to communicate with the database server 62.However, Java applets are only allowed to communicate with the serverthat the applet is originated or downloaded from due to securityrestrictions. In addition, in a distributed computer applicationenvironment, it is more likely that the database server might be on adifferent server than the application server as shown in FIG. 1. Theseservers may only be reachable by the client using the HTTP protocol.Thus, connecting to the different servers may be difficult and not allthe servers are reachable by the clients because they may be behindfirewalls and proxy servers.

Thus, to establish a connection between the client and the one or moreservers of the distributed computer application system, the HTTPprotocol is the common protocol used to communicate with the servers andthe best way for the applets to communicate with the server is by usingHTTP protocol to be as compatible as possible with the proxy servers andnetwork firewalls. The details of this type of secure connection willnow be described in more detail.

FIG. 2 illustrates more details of the system shown in FIG. 1 whereinthe client 22 is executing a database distributed computer applicationand needs to access data stored on a database server 62 wherein theclient is behind a corporate firewall 64. In more detail, each client 22may further include a database client application 70, that may be one ormore Java applets downloaded from the application server 60 and beingexecuted by the client computer and a database proxy object 72 thatcommunicates with the application server 60 as shown to request data.The application server 60 may further include a set of Java servlets 74(which are Java applets that are executed by the application server andwhose user interface is served to the client computer as one or more webpages as is well known) and a set of database drivers 76 that access thedata stored in the database server 62. In the example herein, thedatabase drivers may be JDBC drivers. The set of servlets 74 help createthe connections between the client and the application server and thedatabase server, execute the database statements/queries on theapplication server, and return the database query results back to theclient. The client interacts with the application server using thestandard HTTP protocol.

In a preferred embodiment, other Java classes required both on theserver and the client are the javax.sql package provided by JavaSoft.The common classes required by both the client and the server should bethe same version of compiled classes as a requirement for serializingand deserializing. Now, an example of the method for accessing data inaccordance with the invention will be described.

FIG. 3A illustrates an example of a method 100 for accessing data inaccordance with the invention. In particular, an applet being executedby the client as part of the database client application 70 may make arequest to the servlet 74 using the HTTP protocol with an object name, amethod name, and the parameters required to execute the method in step102. The Servlet 74 in turn responds to the request by executing themethod in step 104 (including accessing the database server). Theservlet may then receive the results of the query in step 106 and passthe results back to the client in step 108 using the HTTP protocol. Inaccordance with the invention, HTTP-JDBC clients (as described below)together with Java's JDBC 2.0 API extension classes provide a better wayfor the applet to communicate with the servlets and provide the clientswith the database driver functionality. Now, each portion of the systemshown in FIG. 2 will be described in more detail.

To execute the distributed computer application in accordance with theinvention, the application server 60 in accordance with the inventionmust have all of the drivers for the databases since these will not bedownloaded to the clients for use by the applets. Thus, each client willnot make connections directly to any database server so that thesecurity problems may be avoided. In turn, the applets on the client maycommunicate with the servlets to do all of the database calls. The setof appropriate proxy objects 72 will communicate with the actual objectson the server as necessary.

On the server side, these driver classes 76 require the set of servlets74 for creating and managing the objects created by calls from theHTTP-JDBC clients. These servlets use Java's reflection to reflect thespecified public method of the object, and execute it, and return theresults to the client. If a resultset is to be returned to the client,then a javax.sql.CachedRowSet object is created and returned to theclient. The CachedRowSet object implements both a resultset andserializable interfaces which makes it easy to serialize it fortransporting it back to the client and the client can treat it as aresultset.

All the objects created on the server are added to a hashtable withtheir unique name as the key. When the client makes a request to executea method on an object by passing the unique name, the servlet gets itfrom the hashtable. These objects are available on the server as long asthe session is active. Once the session is invalidated, the objectscreated in the session are closed, if they need to be closed, and theyare removed from the session and the database connection is disposed offthus freeing all the resources associated with the database connections.These closed objects are then removed from the hashtable and will beavailable for garbage collection.

Each client 22 uses the typical HTTP protocol to communicate with theapplication server. The classes provided by the database vendor may notbe serializable and may not be passed to the server and vice-versa.Thus, in this model, the client 22 may create the set of proxy objects72 whose methods will mirror the methods of the JDBC objects created onthe server. The client may then use these proxy objects 72 tocommunicate with the servlets 74. A new HTTP session is created on theclient for each call to the DriverManager.connect( ) object. This objectis the proxy for the actual session object on the server used later toexecute methods and create statements on the server.

Since there is always a delay in connecting to the server via HTTP, thecalls from the client to the server are batched for better performance.When a batch of statements are sent to the server for execution, theserver executes them in the sequence they are created and returns theresultset along with the unique name of the actual object on the server.The proxy object 72 holds this name for contacting the object at a latertime for executing another batch of methods on the same object.Depending on the method executed, the server will return either aresultset such as a unique name of a new object (e.g., Connection,Statement, PreparedStatement etc.) created on the server, or a nullobject. All the exceptions thrown by the server are serialized and sentto the client, if they should occur. If the execution of the methodresults in creating a new object on the server, then the unique name ofthe object is returned to the client. By overriding the finalize( )method, as the proxy objects are garbage collected on the client, theactual objects will also be removed from the server and are also garbagecollected.

Since the actual objects are created and held on the server, as requiredby the client, the proxy objects on the client are responsible forreleasing them when they are not required. The calling of the close( )method on the JDBC statement object releases all the resources held bythe object. The servlet on the server maintains a list of active objectsand it becomes the job of the servlet to remove all the references ofthe closed object to release all the resources on the server. When aclose( ) method is called on an object, the servlet closes the objectand also removes it from the list. If an object has a close( ) method,then the proxy object's finalize( ) method is overridden to call close() if it is not already closed. The finalize( ) method on Java object iscalled when the object is out of scope of the executing program, and hasno references to it. This approach allows for better clean up ofinactive objects on the server, thereby minimizing the memoryrequirements and maximizing the server performance. The functioning ofthe HTTP JDBC driver in accordance with the invention will be describedin more detail now with reference to FIG. 3B.

FIG. 3B is a block diagram illustrating a preferred embodiment of themethod for using the HTTP JDBC driver in accordance with the inventionwherein the client 22, the application server 60 and the database server62 are shown along with the communications network 26. The diagramillustrates the interaction of the various Java classes that implementthe method. To understand this diagram, a brief description of the Javaclasses is now provided. A more detailed description of the Java classesis provided below.

Client Classes

These classes are downloaded as part of the applet to the client. Theseclasses are used to create proxy objects for communicating with theserver. These classes are responsible for serializing the object thatencapsulates the database calls and de-serialize the results receivedfrom the server.

Common Classes

Since the classes that implement the JDBC interfaces are notserializable, the client needs to communicate with the server usingserialized objects. For serialization to work, some of the same classesare needed, for serializing and deserializing, on both the client andserver. These set of common classes are to be installed on the server,and the same classes are to be downloaded to the client along with theapplet. These set of classes also consist of JDBC 2.0 extension classes.

Server Classes

These classes are available on the application server and delegates thedatabase calls between the database server and the applet. These classesprimarily consist of a servlet and the supporting classes for processingthe HTTP-JDBC calls from the client. These classes are responsible forde-serializing the object that encapsulates the database calls, executesthe database call using the JDBC driver installed on the server, andreturning back the results by serializing them.

Operation of Objects

While client and server objects function in isolation, the objectscreated using common classes are transported between the applet and theservlet. The serialized objects are tunneled through using HTTP betweenthe client and the Java application server. When a query is executedwhich causes to return a table of data, java.sql.ResultSet object iscreated and returned. The server side classes of the HTTP-JDBC driveralso makes use of the JDBC extension classes likejavax.sql.CachedRowSet, which is sent back to the client from theserver. Java.sql.ResultSet interface do not extend java.io.Serializableinterface and so may not be capable of serializing. So, to solve theproblem with serializing result sets to the client we create aCachedRowSet object from the result set and serialize it and return tothe client.

The reason for creating proxy objects is because the objects created onthe server when a database call is made are not transportable to theclient as a Java object. For an object to be transportable it should beable to be serialized and de-serialized. The server application createsa javax.sql.CachedRowSet from thejava.sql.ResultSet.javax.sql.CachedRowSet creates a serializable objectfrom the java.sql.ResultSet object and since this also implementsjava.sql.ResultSet interface, the client application can just treat itas an object of type java.sql.ResultSet. There are many factors toconsider in determining whether or not to transport objects and, in someinstances, transporting objects is simply not viable. In these and otherinstances, it may be better to use proxy objects. Therefore, in thepreferred embodiment of the invention, certain objects are transportedand certain objects are proxied, as discussed herein.

Returning to FIG. 3B, the different steps performed during the securedata access in accordance with the invention using the HTTP JDBC driversare shown as numbers inside of boxes (e.g., 1-6) wherein there may beinteractions between more than one object or class during each step. Forexample, in the first step, the HTTPJDBCConnection, theHTTPJDBCPreparedStatement, the HTTPJDBCStatement, theHTTPJDBCCallableStatement and the HTTPJDBCDriver communicate with theHTTPJDBCSession class as shown.

The following steps are performed wherein the interaction of the objectsand classes are shown in FIG. 3B.

1. An object of type InObject is created if it is a single call. AMethodList object is created if the call can be batched wherein theMethodList object consists of one or more InObjects for executing in aparticular sequence on the server.

2. When a statement is executed on the client, the InObject isserialized and sent to the server for execution by the HTTPJDBCSessionobject which sets up the object for execution on the server.

3. The HTTPJDBCSession object calls the servlet (JDBCServlet) and passesthe InObject to it. The Servlet receives the InObject along with thename of the actual object to execute the method on and the session inwhich the actual object exists. The servlet then retrieves the actualobject from the list using the name and executes the method on theobject.

4. The Servlet receives the return value from the actual object afterexecuting the method.

5. The Servlet returns the value back to HTTPJDBCSession over thecommunications network using the HTTP protocol.

6. The HTTPJDBCSession object returns the value back to the proxy objectwhich generated the method. The proxy object returns the results back tothe calling program.

In more detail, the first step in a JDBC application is to create adatabase connection. This is done by loading the class of theappropriate driver. By doing so, all the connections are made byspecifying a URL that will use the appropriate driver to make aconnection. When an application wants to use the HTTP-JDBC driver, theHTTPJDBCDriver class is loaded. While making the connection the URL tobe specified may have the protocol as httpjdbc or httpsjdbc. When aconnection is created using this HTTP-JDBC driver the HTTPSession sendsthe URL and properties to connect to the database to the server. Theconnection is made on the server and the Connection object is given aunique name and is added to the list of objects on the server. Thisunique name may be sent back and the proxy object of typeHTTPJDBCConnection is created on the client and the unique name may bethe name of the newly created proxy object. Then the application on theclient may use the connection to execute the sql statements.

HTTPSession object on the client, created when a driver is loaded,contacts the JDBCServlet on the application server and sends theInObject or MethodList object for processing. Application may startusing the HTTPJDBCConnection object just like a JDBC connection object.It may start executing various methods on the Connection object, justlike in a typical JDBC application. When a method called by theapplication is to return a result then the proxy object will send themethod(s) to the HTTPJDBCSession. HTTPJDBCSession object then makes aconnection to the servlet on the server and sends the method(s) in onecall. The JDBCServlet executes all the methods on the object in the samesequence as they are called on the client and returns the results to theHTTPJDBCSession object which in turn may return this back to the proxyobject as a return value. Since the application that made the call onthe proxy object is expecting a return value, the proxy object returnsit to the application.

The JDBCServlet will use the unique name of the object to get the objectfrom the list and execute the method, or sequence of methods on theobject. Since the object on the server are JDBC objects, these objectsare responsible for performing the required actions by connecting to thedatabase and returning the values back. The JDBCServlet send back theOutObject which has the result after executing the method(s) and alsothe unique name if the servlet results in creating a new JDBC object onthe server.

The table below illustrates an example of the key proxy objects andother key client-side objects of the HTTPJDBC driver, in the leftcolumn, and the corresponding server-side objects of the typical JDBCdriver, in the right column. The purpose of the following table is toshow a relative comparison between typical key JDBC driver objects andthe key objects of the present invention in order to demonstrate acomparison of function and the relative differences.

TABLE 1 Client Proxy Classes Conventional JDBC Classes HTTPJDBCDriverjava.sql.Driver HTTPJDBCConnection java.sql.Connection HTTPJDBCStatementjava.sql.Statement HTTPJDBCPreparedStatement java.sql.PreparedStatementHTTPJDBCCallableStatement java.sql.CallableStatementHTTPJDBCDatabaseMetadata java.sql.DatabaseMetadata CachedRowSetjava.sql.resultset

An example using the HTTP-JDBC Driver is shown below as a piece of code.

// creates a Connection object on the server HTTPJDBCConnectionconnection = HTTPJDBCDriver.connect(URL, properties); -- start batchHTTPJDBCPreparedStatement pstmt = connection.prepareStatement(Stringstmt); pstmt.setString(1, String); pstmt.setInt(2, int);pstmt.setDate(3, Date); ResultSet rset = (ResultSet)pstmt.executeQuery(); // CachedRowSet object is returned pstmt.close( ); rset.close( ) --end batch.

Now, a technique for downloading the drivers in accordance with theinvention will be described. The distributed computer application systemrequires a set of classes that are to be downloaded as part of theapplet to the clients. The servlets must be registered on the serverwith a Servlet container. The registering of a servlet will deploy theservlet each time a server is started or restarted. A set of initialarguments can be provided to the servlet when it is registered. Someservlet containers allows the registered servlets to work in thesecurity framework of the server, by defining access controls. Inaddition, all of the drivers must be installed on the server and madeavailable to the servlets. The drivers may be loaded by the servlet whenrequired.

The details of the various Java classes used in the preferred embodimentwill now be described. In the attached Appendices (Appendix A, AppendixB and Appendix C), the source code for the various novel classes beingdescribed herein is provided. The server side classes may includevarious classes. For example, the server side classes may include aJDBCServerlet wherein this servlet, that is registered on the server, iscalled from the client with the method or batch of methods to beexecuted on the application server and return the results back to theclient. The server may also include a ServerSessions class which is anobject on the server created for each client session that is responsiblefor holding the JDBCServerSession objects (described below) created bythe servlet. The server may also include a ServerSessions class whichholds the active JDBCServerSession object that is created for eachHTTPJDBCSession on the client. The JDBCServerSession object maintainsall of the objects created for a session in a list. This class has themethods to close an object, if it can be closed, and remove it from thelist. A SQLServer class is a particular implementation showing how toconnect to a SQLServer database, depending on the properties provided bythe client using the appropriate driver. The server may also include anOracle class which is a particular implementation showing how to connectto a Oracle database, depending on the properties provided by the clientusing the appropriate driver. The server may also include aDBConnectionFactory which is used by the JDBCServlet to createconnections to different databases and return them as typejava.sql.Connection. The server may also include a DBVendor class thatprovides a common interface for implementing how to connect to adatabase using the driver provided by a database driver vendor.

In a preferred embodiment, there may be a number of shared classes thatare shared between the client and the server. These classes may includean InObject which is a class that is responsible for creating the typesfor each parameter and is sent to the server along with the values forthe parameters. The servlet takes this object and finds the correctobject from the list depending on the session name and object name. Theserver then executes the method this object represents and returns thevalue back to the client. An object of the type InObject is created foreach method call. The classes may further include a MethodList classthat extends java.util.ArrayList and holds all the methods to beexecuted as a batch. Each element in this list is of type InObject. Whenthe server completes executing the batch it adds a name to thisMethodList and sends back to the client along with the unique name. ANullObject is also included in the common objects since a null valuecannot be serialized and transported back to the client. In particular,this object will be returned when a method call results in returning anull object. The common classes may further include an OutObject whichis returned to the client along with a unique name and the resultset.

In a preferred embodiment, there may be a number of client classes thatreside on the client. These classes may include aHTTPJDBCCallableStatement class that extends java.sql.PreparedStatementand implements the java.sql.CallableStatement interface. This proxyobject is created on the client when the HTTPJDBCConnection.prepareCall(. . . ) is executed. The actual object of type CallableStatement iscreated on the server and the unique name is sent back to the proxyobject on the client which holds it. The client may also include aHTTPJDBCConnection class that extends JDBCStub (see below) andimplements java.sql.Connection interface. This proxy object is createdon the client when the HTTPJDBCDriver.connect( . . . ) is executed. Theactual object of type java.sql.Connection is created on the server andthe unique name is sent back to the proxy object on the client whichholds it. The client may further include a HTTPJDBCDatabaseMetaDataclass that extends JDBCStub and implements java.sql.DatabaseMetaDatainterface. This proxy object is created on the client when theHTTPJDBCConnection.getMetaData( ) is executed. The actual object of typeDatabaseMetaData is created on the server and the unique name is sentback to the proxy object on the client which holds it. The clientfurther includes a HTTPJDBCDriver class that implements thejava.sql.Driver interface. All of the connections created using thisdriver will be of type HTTPJDBCConnection. This follows the standardprocedure for writing JDBC driver java.sql.Driver specifications fromJava Soft. This creates a HTTPJDBCSession on the client and also opens acommunication channel with the server for executing all JDBC calls.

The client may further include a HTTPJDBCPreparedStatement class thatextends HTTPJDBCStatement and implements java.sql.PreparedStatementinterface. This proxy object is created when theHTTPJDBCConnection.prepareStatement( . . . ) is executed. The actualobject of type PreparedStatement is created on the server and the uniquename is sent back to the proxy object on the client which holds it. AHTTPJDBCSession is the object that is responsible for serializing anddeserializing the InObject or the MethodList depending on the type ofcall that is made and sent to the server and the OutObject orCachedRowSet object that is sent back. A HTTPJDBCStatement is a classthat extends JDBCStub and implements javasql.Statement interface. Thisproxy object is created when the HTTPJDBCConnection.createStatement( )is executed. The actual object of type Statement is created on theserver and the unique name is sent back to the proxy object on theclient which holds it. A JDBCStub is a client side class only that has aset of methods that is extended by any class that needs to hold a uniquename. Now, to better understand the invention, the differences betweenthe typical JDBC driver and the HTTP JDBC driver in accordance with theinvention will now be described.

The differences between the typical JDBC driver and the HTTP JDBC driverin accordance with the invention will illustrate the advantages andbenefits of the HTTP JDBC driver in accordance with the invention. Forexample, the applet requirements for connection to a database isdifferent. In particular, for the typical JDBC drivers, the drivers haveto be downloaded to the client along with the applet. This isproblematic since the drivers may be bulky and the client may take along time to download all of the required classes to start using thedriver. If the client needs to connect to different databases withdifferent drivers, then all of the compatible drivers have to bedownloaded at invocation of the applet. If the database does not have apure JDBC driver, then additional software may be required to beinstalled on the client with the applet is invoked. Using the HTTP JDBCdrivers in accordance with the invention, only a small set of classesneeds to be downloaded along with the applet to the client. In addition,since connecting to multiple databases is made possible on the serverside, none of those drivers to connect to the multiple databases needsto be downloaded to the client. Thus, the HTTP JDBC driver alone willmake it possible to connect to different database servers. This model inaccordance with the invention will even support JDBC drivers whichrequire additional software, since they will be installed on the serveritself instead of the client. The HTTP JDBC driver in accordance withthe invention provides the faster downloading of applets to the clientssince these drivers make the clients thin, when it comes tocommunicating with the database servers.

The typical JDBC drivers also differ from the HTTP JDBC drivers in theirprotocol requirements. In particular, the JDBC drivers typically useproprietary protocols for communicating with the server so that eachvendor may have different network protocol requirements. Thus, eachdifferent database may require its own protocol and hence must bedownloaded to the client applet. In contrast, the HTTP JDBC driver usesthe HTTP protocol to proxy the calls over HTTP to the application serverlayer. Then, the JDBC drivers available on the server are responsiblefor communicating with the database server and returning the results.The HTTP JDBC driver in accordance with the invention thus requires nospecial configuration at the client level. In addition, no matter whatprotocol the driver actually uses, that specific protocol is handled bythe application server and the protocol is only utilized between theapplication server and the database server.

The typical JDBC driver also differs in the way that it may establish aconnection as opposed to the HTTP JDBC drivers. In particular, thetypical JDBC drivers connect directly to the server from the downloadedapplet, if all the security, firewall and proxy requirements are met.The JDBC connection is based on parameters supplied to the databasedriver. The problem is that each database vendor uses differentprotocols and ports to connect to their database servers. In addition,due to the security restrictions in using applets, JDBC driversdownloaded to the client along with the applet may not be able tocommunicate with the database server because the database server may notbe on the same host as the applet that was downloaded to the client sothat the applet is not permitted to communicate with the databaseserver. Furthermore, protocol and port requirements to connect to thedatabase servers may not be satisfied in corporate environments. TheHTTP JDBC driver in accordance with the invention connects to thedatabase via the application server layer and uses the same protocol andport that the client uses to download the applet thus making it moresecure. In addition, since the application server actually establishesthe connection, this process may take less time due to the network speedand processing capabilities of the servers. The advantages of bettersecurity and faster response times result from the use of the standardwell known HTTP protocol and its standard ports, such as port 80.

The typical JDBC drivers and the HTTP JDBC driver in accordance with theinvention also differ in the technique for sending SQL statements forexecution. In particular, for the JDBC driver, when a statement iscreated, it is sent to the server immediately for compiling, after whichthis is ready for execution. In contrast, for the HTTP JDBC driver, astatement is sent to the application server, when it needs to beexecuted, for compilation and execution in batch mode all at the sametime, using the built in batching techniques wherein one or moredatabase requests are combined together in a single request. Thebatching of the SQL statements reduces the number of calls to theapplication server, thereby improving the performance and speed of thesystem.

The typical JDBC driver and the HTTP JDBC driver in accordance with theinvention also differ in the way that they process the results. Inparticular, for the typical JDBC driver, the client, after executing theSQL statement, receives the results from the database and processesthem. In contrast, with the HTTP JDBC driver in accordance with theinvention, the server executes the statement, receives and processes theresults, creates a “serializable” object(CachedRowSet) and sends itusing the HTTP protocol to the client. Thus, the processing of resultsand the computation load for the processing is shared by both server andclient so that it may be executed more quickly. An example of the abovedifferences will now be described with reference to FIGS. 4 and 5 tobetter illustrate those differences.

FIG. 4 illustrates a typical JDBC client database connection system 120.In particular, an applet client 122 is shown that is located behind afirewall 124. With this typical arrangement, the client applet mayinclude the JDBC drivers which has the disadvantages set forth above.The system may also include a Java application server 126 and a databaseserver 128 that interact with the client in order to retrieve data fromthe database. As shown, to accomplish this task using this typicalsystem and connection, the applet and the Java application server mayinteract and communicate with each other over Port 80 as is well known.Then, the client applet must communicate directly with the databaseserver using the JDBC drivers and a typical socket connection using port1521 which is the usual port for database access. As described above,this configuration is problematic since the client applet may be unableto connect to the database server using port 1521 due to the firewall.In the alternative, it is necessary that the firewall is programmed toallow the applet to connect to the database server running on port 1521which leaves a hole in the security of the firewall that can beexploited.

The following piece of code illustrates how a typical applet can connectto the database server using JDBC drivers that are downloaded along withthe applet as shown in FIG. 4.

// load the appropriate driver for connecting to the desired databaseserver, Oracle // Sybase, or SQL Server Class.forName(“jdbc.DriverClassName”); // connect to the database at the specified URLwith the login and password // URL string specifies the database host,server name, port other required parameters to connect to //thedatabase. Connection con = DriverManager.getConnection(URL, “myLogin”,“myPassword”); Statement stmt = con.createStatement( ); Connection con =DriverManager.getConnection(URL, “myLogin”, “myPassword”); Statementstmt = con.createStatement( ); ResultSet rset =stmt.executeQuery(“select * from table”); While (rset.next( )){ Stringcol1Value = rset.getString(“column1”); // get the values from theresultset }

Now, the HTTP JDBC driver in accordance with the invention that has theabove described advantages and benefits over the typical client appletwith JDBC drivers will be described.

FIG. 5 illustrates a connection to a database using the HTTP JDBC driversystem 130 in accordance with the invention. In particular, an appletclient with the HTTP JDBC drivers 132 is shown behind a firewall 134. Inparticular, the firewall separates the applet client from an Javaapplication server 136. To request data from a database server 138, theapplet client may generate an HTTP request that passes through thefirewall to the application server over the typical port 80. Theapplication server, with JDBC drivers installed in accordance with theinvention, may then generate a database request and then create a socketconnection over port 1521 to the database server as shown withoutpassing through the firewall. The application server may receive theresponse from the database server and then forward the response back tothe applet client using the typical HTTP protocol. As shown, with thesystem in accordance with the invention, the applet client does not haveto attempt to access the database server directly and the socketconnection between the application server and the database server is notinterfered with by the firewall.

The following piece of code illustrates how a HTTP JDBC applet inaccordance with the invention requests data from the database serverusing the HTTP JDBC drivers in accordance with the invention.

// load the HTTP-JDBC Driver using the appropriate class nameClass.forName(“com.VSDV.HTTPJDBC.Client.Driver”); // connect to thedatabase at the specified URL with the login and password // URL stringspecifies the protocol, database host, server name, port other required// parameters to connect to the database // While using the HTTP-JDBCdriver the protocol should be httpjdbc or httpsjdbc Connection con =DriverManager.getConnection(URL, “myLogin”, “myPassword”); Statementstmt = con.createStatement( ); ResultSet rset =stmt.executeQuery(“select * from table”); While (rset.next( )){ Stringcol1Value = rset.getString(“column1”); // get the values from theresultset }

The HTTP JDBC driver system in accordance with the invention may be usedwith various different JDBC drivers. In particular, since the driversystem in accordance with the invention uses proxy objects tocommunicate with the application server, any type of JDBC driver can besupported without any change to the existing code. In other words, allof the JDBC driver types can be supported without having the clientsdownload any code so that no installation of the drivers is required onthe client. Thus, the HTTP JDBC driver system is adaptable and can beused with any past, current or future JDBC driver. In addition, theservlets of the application server that are executed when a JDBC call ismade can use any type of driver available for a specific platform. Thisdriver can support any or all the types of drivers that are availablefor the platform that the application server is installed. These typesof drivers may include the following:

Type 1—JDBC-ODBC bridge plus ODBC driver;

Type 2—Native-API partly-Java driver;

Type 3—JDBC-Net pure Java driver; and

Type 4—Native-protocol pure Java driver.

For more information on these types of drivers refer to the driver typesdocumentation page athttp://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/intro.html#1018502.Now, the advantages of using the HTTP JDBC driver system in differentscenarios will be described in more detail.

The downloading of the code to the client as part of the applet andcreating proxy objects on the client for communicating with the JDBCobjects gives the clients enormous power during runtime. For example, aclient may dynamically connect to any database through the applicationserver if the suitable drivers are loaded on the server. Since the JDBCcommunication is proxied by the client, all that is needed are the setof parameters for connecting to a database server. If a JDBC compliantdriver can be found for the Java application server then the client cancreate a proxy object to communicate with the database connection objecton the server. In fact, regardless of the protocol and communicationrequirements for a particular database, the client code does not changeand no additional code will need to be downloaded for connecting to adifferent database. In addition, the client side of the driver candelegate calls to any database provided the application server has thesuitable driver for connecting to the database. Unlike traditional JDBCdrivers that are different for each different database, the HTTP JDBCdriver in accordance with the invention remains the same for accessingany database. A first scenario that may use the HTTP JDBC driver inaccordance with the invention is a client/server system.

In this scenario, the database server and the Java application serverare both on the same physical machine/computing resource. The clientthat is accessing the application is behind a firewall. The firewallallows only HTTP protocol communications and permits connections to aparticular port, typically port 80. Both the web service provided by theJava application server and the database server cannot listen forincoming requests on the same port and both the services use differentprotocols. Thus, even though the applet is allowed to make socketconnections to the server it is downloaded from, the firewall mightprevent this from occurring when using a traditional JDBC driver. Thus,the HTTP-JDBC driver can be very useful in this scenario.

In another scenario, the database server and the application server areon separate physical machines and have different IP addresses. This isthe scenario that was shown in FIG. 2 and described above. In anotherscenario, the application server may be a client for another applicationserver. FIG. 6 illustrates a system 140 wherein an application server142 is being used as the client for another server in accordance withthe invention. In particular, a client 144 may connect and communicatewith the application server 142 wherein the client and applicationserver are both on the same side of a firewall 146. On the other side ofthe firewall is a second application server 148 and a database server150. In more detail, the Java application server 142 behind a firewallwould become a client to another Java application server 148 that isoutside the firewall and has access to the database 150. Thisarchitecture is very useful for server side programs requiring databaseaccess to disparate data sources wherein all the security restrictionscan be overcome by using the HTTP-JDBC driver in accordance with theinvention. In one embodiment, the HTTP JDBC driver system may be used byall the J2EE components that are provided by the Java application serverthat requires database access.

In another scenario, the HTTP JDBC driver in accordance with theinvention may be used effectively in distributed computing. Inparticular, the HTTP-JDBC driver will provide a solution for connectingto disparate and/or external data sources in a distributed computingenvironment. Since the HTTP JDBC driver is based on the most commonInternet communication protocol, the driver can be used by any device ina network that has a Java runtime environment with HTTP protocolsupport. In addition, since the technology for distributed computingusing Java components is emerging and evolving rapidly, any Javacomponent in a Java enabled distributed environment can efficiently useHTTP-JDBC driver to gain access to disparate data sources

In another scenario, the HTTP JDBC driver may be used with JiniServices. The Jini technology enables open end-to-end solutions forcreating dynamically networked products, services, and applications thatscale from device to the enterprise. The HTTP-JDBC driver may be used toprovide dynamic database access to a wide variety of databases and otherdata sources that are required by a Jini service. Since Jini clients canbe behind secure networks, the same problems, explained earlier, arisewhen trying to connect to the database using a protocol and a port thatis prohibited by the firewall. Because of the advantages this has overtypical JDBC drivers, explained earlier, this will provide a bettersolution both in terms of downloading a small piece of code anddelegating all the database access to the Java application server thatis outside the firewall and has access to the database server. Thisdriver can be snapped in to a service dynamically and provide thedatabase access without the communication restrictions of the firewall.In this scenario the database connectivity parameters may be provideddynamically depending on the client requiring access to the database.

In another scenario, the driver may be used with peer-to-peer computingsystems such as project JXTA. In particular, in a Java peer-to-peerenvironment, the driver in accordance with the invention may be used toaccess a disparate data source without having to download a lot ofclasses while using the most common internet protocol HTTP. Since JXTAdoes not specify any language requirements, this driver can support anytwo peers in which one peer has a Java virtual machine and the other hasa Java application server. Since the HTTP-JDBC driver can work onclients with a small memory footprint this can be used by virtually anydevice in a peer group that has the Java runtime environment. Since JXTAspecification does not specify that the peers be developed in aparticular language for interoperability, this driver can support anypeer in a peer-to-peer environment with a Java virtual machine and HTTPsupport. The peers can use this driver to gain access to a databaseoutside of the firewall by connecting to a Java application server anddelegating all the database communication to the server side componentsof the driver installed on the application server.

In more detail, Project JXTA addresses the need for an open, generalizedprotocol that inter-operates with any peer on the network including PCs,servers and other connected devices. The goal of project JXTA is todevelop basic building blocks and services that would enable innovativeapplications for peer groups. A peer can offer a service by itself or inco-operation with other peers. In a peer-to-peer service model, if aservice should provide access to a database, then using this driverwould make access to the database simple and efficient. If a peer was togain access to a database outside of the firewall then using this driverwould make it easier to penetrate the firewall using the most widelyused protocol HTTP and port 80. In this environment the parameters toconnect to a database might vary from service to service or even at apeer level, this driver provides an efficient way of gaining access tothe database because of all it's virtues explained above.

In a peer group one of the peers can provide this driver as a part ofthe peer group service to connect to any database. The peer deliveringthis service component can have all the required drivers to connect todifferent databases or it can discover these drivers available on thenetwork and provide the database access to the required database.

Additional details of the HTTP tunneling, servlets and session trackingused to implement the HTTP JDBC driver in accordance with the inventionmay be found at the locations below. The information located at thoselinks are incorporated herein by reference.

]HTTP Tunneling

http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/Burrowing/index.html

http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/JDCPerformTips/

Servlets and Session Tracking

http://java.sun.com/docs/books/tutorial/servlets/client-state/sessio-n-tracking.html

http://java.sun.com/j2ee/tutorial/doc/Servlets11.html

http://java.sun.com/docs/books/tutorial/servlets/TOC.html

While the foregoing has been with reference to a particular embodimentof the invention, it will be appreciated by those skilled in the artthat changes in this embodiment may be made without departing from theprinciples and spirit of the invention, the scope of which is defined bythe appended claims.

1. An apparatus for accessing data from a database through a securitymechanism, the apparatus comprising: a first application capable ofbeing executed on a client computer; one or more proxy objects beinggenerated in response to commands from the first application, the proxyobjects requesting data from a database; one or more drivers capable ofbeing stored on a server computer; and a second application capable ofbeing executed on a server computer separated from the first applicationby a security mechanism, the second application receiving the proxyobjects from the first application, generating a database query based onthe proxy objects and the drivers and returning the database queryresults to the first application.